Network operators and carriers are deploying packet-switched communications networks in place of circuit-switched networks. In packet-switched networks such as Internet Protocol (IP) networks, IP packets are routed according to routing state stored at each IP router in the network. Similarly, in Provider Ethernet networks, Ethernet frames are forwarded according to forwarding state stored at each Ethernet switch in the network. In this document, the terms “packet” and “packet-switched network”, “routing”, “frame” and “frame-based network”, “forwarding” and cognate terms are intended to cover any PDUs, communications networks using PDUs and the selective transmission of PDUs from network node to network node.
The modern packet network space is composed of multiple autonomous domains, each of which is managed by an independent network operator entity. For the purposes of understanding the present disclosure, an “autonomous domain” should be understood to refer to a collection of connected network elements, including, but not restricted to Ethernet Switches, under control of a network operator. In Internet Protocol (IP) networks, autonomous domains are referred to as “autonomous systems”, and may in fact be controlled by more than one entity. In Ethernet networks, an autonomous domain may be referred to as a sub-network, or simply a network. However, in all cases, customers (or subscribers) access the autonomous domain under the terms of a service agreement with the network operator that controls the specific domain to which the customer wishes to connect. Typically, an autonomous domain is connected to one or more adjacent autonomous domains via one or more border gateway devices, which may enable a customer to exchange packets with network addresses outside of the specific domain to which the customer is connected.
In the provision of services such as Virtual Private Network (VPN) service, a customer will have two or more sites which are desired to be linked using a given network service instance. For example, a company may have sales offices at multiple locations, and desire to connect all of these offices using an Ethernet multi-point to multi-point (known as ELAN) service instance. If all of the customer sites are located within the territory served by a single autonomous domain, then it is a simple matter for the domain's network operator to provide the desired service to all of the customer's sites. However, it often happens that the customer's sites are geographically dispersed to such an extent that they cannot all be directly connected to the same autonomous domain. For example, a company may have sales offices in multiple different countries, and each sales office will necessarily connect to an autonomous domain that covers the region in which that office is located. In this case, some means must be provided to extend the desired service (e.g. ELAN) across all of the involved autonomous systems.
From the network operators' point of view, extending a service instance across two or more domains requires coordination of packet addressing and labelling schemes (so that, for example, packet traffic identified in one domain as belonging to a specific VPN service instance is properly recognised as such in each of the other involved domains), Operation Administration and Maintenance (OAM) as it pertains to the extended services, customer billing and financial reconciliation between each of the network operators. From the customer's point of view, this coordination should ideally be transparent. Ideally the customer wants to deal with a single service provider for set up, technical support and maintenance, and receive a single invoice.
Known methods of addressing these issues include network federation and negotiation of inter-operator agreements for each service instance. Network federation is a technique in which the network operators controlling one or more autonomous domains agree to unify some aspect of their network OAM functionality. For example, the allocation of packet labels to network service instances may be co-ordinated into a single cross domain management scheme, so that VPN traffic can be properly recognised and handled in each of the federated networks (or domains). Inter-operator agreements can be used, for example, to provide uniform bandwidth allocation to a specific service instance across multiple domains, and reconciliation of charges between the involved operators. When the number of domains in a federation, and/or the number of customers that require services that span multiple domains, is limited, these arrangements are generally satisfactory. However, successful federation of autonomous domains become increasingly complex as the number of member domains increases. Similarly, negotiation of inter-operator agreements for each service instance, and the subsequent co-ordination of provisioning and billing, becomes increasingly complex and onerous as the number of customers requiring multi-domain services, and as the number of involved domains, increases.
Techniques for extending network services of a first domain to a remote customer site in a Provider Ethernet domain, which overcome at least some of the above-noted issues remain highly desirable.